Switch from unreliable fork to spawn #40
Conversation
epatey
force-pushed
the
spawn
branch
7 times, most recently
from
635fea0 to
99b3aae
Compare
jjallaire
left a comment
jjallaire
left a comment
There was a problem hiding this comment.
It looks tight to me! The fact that the IPC context already established a clean boundary appears to have made this way less risky/intrusive than it otherwise would have been.
| patch_inspect_log_handler(_log_in_parent) | ||
|
|
||
| # Set up sys.path with plugin directories before any user imports | ||
| for plugin_dir in ipc_ctx.plugin_dirs: |
There was a problem hiding this comment.
Does this mean that we basically get all of the "local" scanner directories in the sys path? (i.e. could they conflict with each other). Chance of this seems highly remote as it would require multiple plugin scanners in different directories so I think it would be fine if it was a "known issue" (or maybe I don't understand this clearly enough).
There was a problem hiding this comment.
@jjallaire, all registered plugin directories get added to sys.path in the MP subprocesses. In practice only one directory gets registered per CLI invocation because scanners_from_file and scanjob_from_file are mutually exclusive.
Multiple dirs could accumulate if someone ran multiple scout scan commands programmatically in the same process. I think the conflict would multiple plugins in different dirs with same module names.
That does seem pretty fringe, so I agree it's fine for this to be a known limitation.
No description provided.